Modern computing systems create tremendous amounts of data of varying sensitivities. One operative question is when data should be destructed and/or archived (hereinafter, ‘destructed’ is taken to mean ‘destructed and/or archived’). Data may be destructed for many reasons, including reducing data storage costs, improving data access performance, business requirements, government regulations, and the like. For example, person-related data may be subject to data privacy regulations which require the person-related data to be destructed when no longer needed by the system.
However, the need to destruct data is balanced against other legal obligations, which often require data to be preserved for certain periods of time. Other requirements, such as data revision, must also be considered when determining when to destruct data. Typically, individual data objects are destructed as a whole.
Data is often stored in hierarchies and/or interconnected graphs of data objects. Whether defined by in-memory references, database foreign key relationships, graph database edges and vertices, or the like, a given data object often holds a reference to another data object. To take one example, business objects typically exist as one of a hierarchy of business objects. A business object is defined as a larger set of data which exists in a system for the purpose of combined handling for the set of data with regard to its contained information, its lifecycle, or its consistent behavior in a process. In one embodiment, the factors that determine when a data object is to be destructed (i.e., retention time rules for destruction and residence time rules for archiving) are common to related data objects. Often, these factors are stored in a single location, such as an attribute of a master data object.
However, as these destruction factors must be available during the destruction of all dependent data objects, a limitation is placed on the sequence of object destruction. Specifically, the master data object must be preserved until all dependent objects have been destructed. This limitation negatively impacts object destruction throughput, and may itself prevent compliance with applicable object destruction regulations and/or business requirements by extending retention of the master data object.
Therefore, there is a need for an improved framework that addresses the abovementioned challenges.